Configuring Call Admission Control

You can implement Call Admission Control (CAC) to regulate the volume of voice traffic handled by the device.

CAC configuration is done using two tables with parent-child type relationship:

■

Call Admission Control Profile table: This is the parent table, which defines a name for the CAC profile.

■

Call Admission Control Rule table: This is the child table, which defines the actual CAC rules for the profile.

You can configure up to 1,500 CAC profiles and up to 1,500 CAC rules. In addition, a CAC profile can be configured with up to 8 CAC rules.

Once you have configured a CAC profile with CAC rules, you need to assign it to any of the following SIP configuration entities (using the 'CAC Profile' parameter):

■

IP Group (see Configuring IP Groups)

■

SIP Interface (see Configuring SIP Interfaces)

■

SRD (see Configuring SRDs)

CAC rules define the maximum number of allowed concurrent calls (SIP dialog-initiating requests) for the assigned SIP entity (listed above) and per registered user belonging to the SIP entity. This can also include the maximum number of allowed concurrent SIP dialogs per second (rate). The CAC rule can be defined for a specific SIP message type (e.g., only INVITEs) as well as for a specific call direction (e.g., only outbound calls).

The CAC feature can be configured to support one of the following rate-limiting algorithms:

■

Sliding Window Counter: This scheme is a very accurate rate-limiting algorithm for SIP dialogs and is based on a sliding window counter, where the window is the last (previous) second. The rate is based on the number of incoming SIP dialog-initiating requests (e.g., INVITE) that were received in the previous second to when a new incoming dialog-initiating request arrives. If the rate is exceeded, the device rejects the SIP dialog request.

For example:

●

Assume the following:

◆

You have configured the rate to 5 (using the 'Rate' parameter). In other words, a maximum of 5 SIP dialog-initiating requests are allowed in the last second (window).

◆

10 SIP sessions exist.

◆

The device receives a new incoming SIP-dialog request at 18:00:01.123 (HH:MM:SS.MSEC).

●

Scenarios:

◆

Scenario #1: Out of the 10 SIP sessions, SIP dialog-initiating requests of only 4 of the sessions were received in the last second (18:00:00.124-18:00:01.123). Therefore, the device accepts the new incoming SIP dialog because the configured rate (5) has not been exceeded.

◆

Scenario #2: Out of the 10 SIP sessions, SIP dialog-initiating requests of 5 of the sessions were received in the last second (18:00:00.124-18:00:01.123). Therefore, the device rejects the new incoming SIP dialog because the configured rate limit (5) has been exceeded.

■

Token Bucket: This scheme is a SIP-dialog rate control using the token-bucket mechanism. Token bucket is a control mechanism that determines the rate of SIP dialog processing based on the presence of tokens in the bucket. Tokens in the bucket are removed ("cashed in") for the ability to process each dialog. If there are no tokens, the device rejects the dialog request with a SIP 480 (Temporarily Unavailable). Configuration of the token-bucket mechanism involves the following:

●

Configuring the number of tokens that are added to the bucket per second. This is referred to as rate. To process (allow) a SIP dialog, the device needs a token from the bucket.

●

Configuring the maximum number of tokens that the bucket can hold and thus, the maximum number of tokens that can be used for processing SIP dialogs that are received at one time. This is referred to as burst.

For example, assume that the rate is configured to 1 and the burst to 4:

●

One token is added to the bucket every second.

●

The maximum number of tokens that the bucket can hold is four.

●

If SIP dialogs have never been received by the device, the bucket is filled to its maximum, which is four tokens (i.e., burst), regardless of the number of seconds that have passed.

●

If four SIP dialogs are received at the same time (i.e., burst), the device uses the four tokens to process the dialogs. The bucket is now left with no tokens at that given moment, but after a second, a new token is added to the bucket (due to the rate). If there are no calls for the next three seconds, the bucket fills up again to four tokens (and no more).

●

If the bucket contains four tokens (i.e., full) and five SIP dialogs are received at the same time, the device uses the four tokens to process four of the dialogs and rejects one.

●

If the bucket has one token and SIP dialogs are then received every second, the device uses the token to process the first dialog, adds a token to the bucket after a second and processes the second dialog, and so on.

Your CAC rule can also define a guaranteed number of concurrent calls (reserved capacity) for the assigned SIP entity (see above) . Reserved capacity is especially useful when the device operates with multiple entities. For example, if the total call capacity supported by the device is 200, a scenario may arise where a SIP entity may reach 200 call sessions, leaving no available call resources for the other SIP entities. If the reserved call capacity of a SIP entity is threatened by a new call for a different SIP entity, the device rejects the call to safeguard the reserved capacity.

Requests that reach the user-defined call limit (maximum concurrent calls or call rate) are sent to an alternative route, if configured (in the IP-to-IP Routing table). If no alternative routing rule exists, the device rejects the SIP request with a SIP 480 "Temporarily Unavailable" response.

The following procedure describes how to configure CAC profiles through the Web interface. You can also configure them through other management interfaces:

■

Call Admission Control Profile table: ini file [SBCAdmissionProfile] or CLI (configure voip > sbc cac-profile)

■

Call Admission Control Rule table: ini file [SBCAdmissionRule] or CLI (configure voip > sbc cac-rule)

➢

To configure a CAC profile:

1.

Configure the rate-limiting algorithm that you want to use for all your CAC rules:

a.

Open the SBC General Settings (Setup menu > Signaling & Media tab > SBC folder > SBC General Settings).

b.

From the 'Sliding Window Counter Rate Limiting Algorithm For CAC' drop-down list, select one of the follow options:

◆

Enable to enable the Sliding Window Counter algorithm.

◆

Disable to enable the Token Bucket algorithm.

a.

Click Apply.

2.

Open the Call Admission Control Profile table (Setup menu > Signaling & Media tab > SBC folder > Call Admission Control Profile).

3.

Click New; the following dialog box appears:

4.

Configure a CAC profile according to the parameters described in the table below.

5.

Click Apply.

Call Admission Control Profile Table Parameter Description

Parameter	Description
'Index' [Index]	Defines an index number for the new table row. Note: Each row must be configured with a unique index.
'Name' name [Name]	Defines a descriptive name, which is used when associating the row in other tables. The valid value is a string of up to 40 characters. By default, no value is defined. Note: ■ The parameter value can't contain a forward slash (/). ■ The parameter value can't be configured with the character string "any" (upper or lower case).

6.

In the Call Admission Control Profile table, select the required row, and then click the Call Admission Control Rule link located below the table; the Call Admission Control Rule table appears.

7.

Click New; the following dialog box appears:

8.

Configure a CAC rule according to the parameters described in the table below.

9.

Click Apply.

Call Admission Control Rule Table Parameter Description

Parameter	Description
Match
'Index' sbc-admission-rule-<Index>/<Index> [SBCAdmissionRule_RuleIndex]	Defines an index number for the new table row. Note: Each row must be configured with a unique index.
'Request Type' request-type [SBCAdmissionRule_RequestType]	Defines the type of SIP dialog-initiating request to which you want to apply the rule (not to subsequent requests, which can be of different type and direction). ■ [0] All (default) ■ [1] INVITE ■ [2] SUBSCRIBE ■ [3] Other = All SIP request types except INVITEs and SUBSCRIBEs (e.g., REGISTER).
'Request Direction' request-direction [SBCAdmissionRule_RequestDirection]	Defines the call direction of the SIP request to which the rule applies. ■ [0] Both = (Default) Rule applies to inbound and outbound SIP dialogs. ■ [1] Inbound = Rule applies only to inbound SIP dialogs. ■ [2] Outbound = Rule applies only to outbound SIP dialogs.
Action
'Limit' limit [SBCAdmissionRule_Limit]	Defines the maximum allowed number of concurrent SIP dialogs. You can also use the following special values: ■ [-1] -1 = (Default) Unlimited number of concurrent SIP dialogs. ■ [0] 0 = Blocks all the SIP dialog types specified in the 'Request Type' parameter (above). Note: The parameter is not related to the rate-limiting algorithms.
'Limit per User' limit-per-user [SBCAdmissionRule_LimitPerUser]	Defines the maximum number of allowed concurrent SIP dialogs per user. You can also use the following special values: ■ [-1] -1 = (Default) Unlimited number of concurrent SIP dialogs per user. ■ [0] 0 = Blocks all the SIP dialog types specified in the 'Request Type' parameter (above). Note: The parameter is not related to the rate-limiting algorithms.
'Rate' rate [SBCAdmissionRule_Rate]	Depends on the rate-limiting algorithm (configured by the 'Sliding Window Counter Rate Limiting Algorithm For CAC' parameter in Step 1): ■ Sliding Window Counter algorithm: Defines the maximum number of allowed incoming SIP dialog-initiating requests in the last second (window). For example, if you configure the parameter to 5 and 5 SIP dialog-initiating requests were received in the last second when a new incoming SIP dialog-initiating request is received, the device rejects the SIP dialog. ■ Token Bucket algorithm: Defines the number of tokens added to the token "bucket" per second, where a token "buys" a SIP dialog. For example, if you configure the parameter to 1, one token is added to the bucket every second. If there are no calls for five seconds, the bucket would have accumulated 5 tokens. The valid value is 0 to 65,535. The default is 0 (i.e., unlimited rate). Note: ■ The parameter is applicable to the Token Bucket and Sliding Window Counter rate-limiting algorithms. ■ If you configure the parameter, you must also configure the 'Maximum Burst' parameter to a non-zero value; unless you are using the Sliding Window Counter rate-limiting algorithm.
'Maximum Burst' max-burst [SBCAdmissionRule_MaxBurst]	Defines the maximum number of SIP dialogs that can be processed at any given time. Token Bucket algorithm: In other words, it defines the maximum number of tokens that the "bucket" can hold. The device only accepts a SIP dialog if a token exists in the "bucket". Once the SIP dialog is accepted, a token is removed from the "bucket". If a SIP dialog is received by the device and the token "bucket" is empty, the device rejects the SIP dialog. Alternatively, if the "bucket" is full, for example, 100 tokens, and 101 SIP dialogs arrive (before another token is added to the "bucket", i.e., faster than that configured in the 'Rate' parameter), the device accepts the first 100 SIP dialogs and rejects the last one. Dropped requests are not counted in the "bucket". The valid value is 0 to 65,535. The default is 0 (i.e., unlimited SIP dialogs). Note: ■ The parameter is applicable only to the Token Bucket rate-limiting algorithm (ignored if Sliding Window Counter algorithm is enabled). ■ The parameter functions together with the 'Rate' parameter (see above). Therefore, the parameter must be configuired. ■ The parameter's value cannot be greater than 10 times (x) the value of the 'Rate' parameter. For example, if you configured the 'Rate' parameter to 2, you can configure the 'Maximum Burst' parameter to any value less than or equal to 20 (i.e., 10 x 2). ■ The token bucket feature is per SIP request type and SIP request direction.
'Rate Per User' rate-per-user [SBCAdmissionRule_RatePerUser]	Defines the maximum allowed number of concurrent SIP dialogs per registered user that can be handled per second. The valid value is 0 to 65,535. The default is 0 (i.e., unlimited rate). Note: ■ The parameter is applicable to both the Token Bucket and Sliding Window Counter rate-limiting algorithms, but it always uses the Token Bucket algorithm. ■ If you configure this parameter, you must also configure the 'Maximum Burst per User' parameter to a non-zero value (see below).
'Maximum Burst Per User' max-burst-per-user [SBCAdmissionRule_MaxBurstPerUser]	Defines the maximum number of tokens (SIP dialogs) per user that the bucket can hold (see the 'Maximum Burst' parameter for a detailed description). The valid value is 0 to 65,535. The default is 0 (i.e., unlimited SIP dialogs). Note: ■ The parameter is applicable only to the Token Bucket rate-limiting algorithm. ■ The parameter functions together with the 'Rate Per User' parameter (see above).
'Reserved Capacity' reservation [SBCAdmissionRule_Reservation]	Defines the guaranteed (minimum) call capacity. The default is 0 (i.e., no reserved capacity). If you configure reserved call capacity for an SRD and each of its associated IP Groups, the SRD's reserved call capacity must be greater or equal to the summation of the reserved call capacity of all these IP Groups. In other words, the SRD serves as the "parent" reserved call capacity. If the SRD's reserved call capacity is greater, the extra call capacity can be used as a shared pool between the IP Groups for unreserved calls when they exceed their reserved capacity. For example, assume that the reserved capacity for an SRD and its associated IP Groups are as follows: ■ SRD reserved call capacity: 40 ■ IP Group ID 1 reserved call capacity: 10 ■ IP Group ID 2 reserved call capacity: 20 In this setup, the SRD offers a shared pool for unreserved call capacity of 10 [i.e., 40 – (10 + 20)]. If IP Group ID 1 needs to handle 15 calls, it is guaranteed 10 calls and the remaining 5 is provided from the SRD's shared pool. If the SDR's shared pool is currently empty and resources for new calls are required, the quota is taken from the device's total capacity, if available. For example, if IP Group ID 1 needs to handle 21 calls, it's guaranteed 10, the SRD's shared pool provides another 10, and the last call is provided from the device's total call capacity support (e.g., of 200). Note: ■ The parameter is not related to the rate-limiting algorithms. ■ Reserved call capacity is applicable only to IP Groups and SRDs. ■ Reserved call capacity is applicable only to INVITE and SUBSCRIBE messages. ■ Reserved call capacity must be less than the maximum capacity (limit) configured for the CAC rule (see the 'Limit' parameter). ■ The total reserved call capacity configured for all CAC rules must be within the device's total call capacity support.